home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
urn
/
urn-archives
/
urn-ietf.archive.9703
/
000104_owner-urn-ietf _Mon Mar 31 14:29:54 1997.msg
< prev
Wrap
Internet Message Format
|
1997-04-01
|
4KB
Received: (from daemon@localhost)
by services.bunyip.com (8.8.5/8.8.5) id OAA28649
for urn-ietf-out; Mon, 31 Mar 1997 14:29:54 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
by services.bunyip.com (8.8.5/8.8.5) with SMTP id OAA28644
for <urn-ietf@services.bunyip.com>; Mon, 31 Mar 1997 14:29:52 -0500 (EST)
Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA01792 (mail destined for urn-ietf@services.bunyip.com); Mon, 31 Mar 97 14:29:49 -0500
Message-Id: <9703311929.AA01792@mocha.bunyip.com>
Received: by privateer.windrose.omaha.ne.us; Mon Mar 31 13:30 CST 1997
From: "Ryan Moats" <jayhawk@ds.internic.net>
To: "Dan Connolly" <connolly@w3.org>,
"Daniel LaLiberte" <liberte@ncsa.uiuc.edu>
Cc: "urn-ietf@bunyip.com" <urn-ietf@bunyip.com>
Date: Mon, 31 Mar 97 13:32:55
Priority: Normal
X-Mailer: PMMail 1.91 For OS/2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Re: [URN] urn: prefix is a brand name?
Sender: owner-urn-ietf@Bunyip.Com
Precedence: bulk
Reply-To: "Ryan Moats" <jayhawk@ds.internic.net>
Errors-To: owner-urn-ietf@Bunyip.Com
On Sun, 30 Mar 1997 13:27:37 -0600 (CST), Daniel LaLiberte wrote:
>Dan Connolly writes:
> > I found another one of the motivations for the urn: prefix,
> > (thanks for the pointer to the WAIS archive!)
> > and it worries me more than any of the other so far:
> >
> > On Tue, 05 Nov 1996 23:16:17 -0500, Keith Moore wrote:
> > >This is why URNs need a URN: prefix -- because a lot of the value in
> > >having a URN name space with those properties is so *humans* can
> > >recognize a URN when they see it.
>
>We got to that point after my persistent (ha!) arguments that "urn:"
>doesn't mean much else. Not everyone agrees with Keith on this point,
>of course.
>
>Ironically, Keith and others also argue for semantically meaningless
>numeric URNs and a higher layer of human friendly identifiers, so humans
>will hopefully never see the "urn:" prefix.
I have a little free time to devote to this, although I do have the gripe that
WG last call on this (urn syntax) has already passed...
Reasons that come to my mind for having "urn:" (I don't claim that anybody
else needs to agree with these...):
1. URNs are NOT URLs.
2. As a corollary to #1, using the same space for URN NIDs and URL
schemes leads to greater collisions than keeping the spaces separate.
For example, I can see a collision occurring between the "cid:" URL scheme
and a namespace of resources set up by some criminal investigation division
(The fact that there are multiple CID organizations in the US attached to
various police departments is an issue for the URN NID space
by itself). Keeping these two spaces separate allows each to
deal with its own collisions and not worry about the other space.
3. Currently (based on my interpretation of URL schemes, your mileage may
vary), each and every URL scheme has a "resolution" "protocol" tied to it.
The URN working group is proposing that initially there be a set of "resolution"
"protocol(s)" for URNs tending toward a single resolution protocol. All
of these are independent of the URN NID. Using
"urn:" at the beginning of the URN provides a syntactic handle for
browsers to recognize URNs as being distinct from URLs.
3a. (#3 has the result that URN-aware browsers do not have to be
modified if a new NID is defined as compared to what is required for
supporting a new URL scheme. An addition to the "family" of resolution
protocols for URNs would require browser modification , but the direction
is for less URN resolution protocols rather than more).
Ryan Moats